[レポート] 行き先は火星?木星? 移住計画用マイクロサービスを AWS サービスで構築・管理する #ENT308 #reinvent #newrelic
re:Invent 2019 にて開催されたスポンサーセッション、ENT308-S「モダンな AWS サービスを用いてマイクロサービスアプリを構築する(Build your next microservices application with modern AWS services)」のレポートをお送りします。
本セッションの録画は既に公開されていますので、興味がわきましたら詳細はそちらで是非ご確認下さい。
TL;DR
ウェブサイトをスピードアップするベストの方法
- 1にキャッシュ、2にキャッシュ
- +AWS
- +New Relic
- A Bunch Of Great Strategies For Using Memcached And MySQL Better Together
- http://highscalability.com/
概要
[抄訳] AWS Lambda, EKS, SQS そして DynamoDB を使ってマイクロサービスアプリケーションの構築を始めることはとても簡単です。このセッションでは実動するデモアプリを通して、実際のデプロイやトラブルシューティングがどのようなものかを学びます。このセッションは New Relic 社がお送りします。
資料
登壇者
- Javier Miguez
- Director, Technology Operations, Fleet Complete
- Nik Jain
- Solutions Architect, New Relic
内容
- (会場アンケート)「まず最初にランダム・サンプリングを。。。みなさんは火星と木星どちら選択しますか?」(挙手)
- 「これがどう重要なのかは、あとで分かりますw」
- アジェンダ
- モダンなマイクロサービスを定義する
- 人間のマイグレーション
- ライブデモ
- 現代的なサービスを構築・管理するための可観測性(Observability)戦略
First Complete 社の変革
- モノリシック時代
- オンプレ + VMware + WindowsOS + SQL Server
- マイクロサービス時代
- オンプレ + k8s + Apache Kafka + redis / PostgreSQL / Spark / mongoDB / Elastic 製品 / RabbitMQ / HAProxy
- 現代的なマネージドテクノロジ
- New Relic + AWS EC2 + IoT Core / Kinesis / Amazon SNS / Fargate / ElastiCache / Lambda / OpsWorks / RDS / EMR / DynamoDB / Amazon ES / Route 53 / SQS / ELB / CloudTrail / Redshift
- 現代的なマイクロサービスのコア要素 = モダンとは?
- DevOps - コードパイプラインの貢献
- <- New Relic, Jenkins
- Auto Scaling対応 - 手動のスケーリングを求めない
- <- EC2 Auto Scaling
- クラウドネイティブ
- <- AWS Lambda, CloudFront
- オーケストレーションによる制御 - オペレーションコストの低減
- <- EKS
- DevOps - コードパイプラインの貢献
EKS + Lambda + Fargateを選んだ理由
- オペレーション的な価値
- 根本的にサーバを気にしなくて済む
- EKS/Fargateは貴方の組織を機敏にする
- <- New Relic, Jenkins
- コスト効率
- トラフィックが発生しなければコストも発生しない
- EKS/Fargateはコスト効率が良い
- <- New Relic, クラウドの課金体系
- 生産性
- より抽象化が進んでいる
- EKS/Fargateはポータビリティが良い
- <- New Relic, k8s
デモ : 大規模宇宙移民アプリケーション
- ここで架空のシチュエーションを想定したゲームタイムを
- 西暦2045年に、地球が住めなくなったと仮定
- 選ばれた65,000人を火星または木星に脱出させる
- 全員分のLast wish(遺言)を残す
- 地球 -> 火星 : 9ヶ月の旅
- 地球 -> 木星(衛星エウロパ) : 72ヶ月
- トラフィックを捌くために、構築にはクラウドリソース(AWS)を活用する
- 言語 : Node.js
- フロントエンド : EKS
- パーサ : Lambda
- Pod Woker : Lambda, Fargate
- DB : DynamoDB
- フロントエンド -> パーサ、パーサ -> Pod Worker間はSQSでつなぐ
- このセッションの参加者で、デモアプリにトラフィックを流して欲しい
Its year 2045. Alas, Earth is Uninhabitable!
Send your wishes to fellow citizens who will be left behind ...
(西暦 2045 年、地球は死の星と化した!
後に残される同胞達に宛てて、貴方からのメッセージを送信しよう……)
- アプリケーションのプロビジョニングについてまとめ
- モダンなAWSサービスは運用が必要な要素を削減する可能性を秘めている
- CFnテンプレートは簡単(リソースのデプロイを自動化する)
- (EKSにおいて)namespaceのレベルに対するクラウドコストを理解する
- 次のデモ : 早急な問題解決にむけた可観測性の利用
- 構成の各要素にNew Relicを仕込んだ
- 実際にトラブルシュートしてみる
デモ : 26:42〜36:11
- 誰かがメッセージにHTMLインジェクションを送ったらしい(想定外)w
- これがNew Relic Oneのダッシュボード
- Overviewの画面で、2つのHostで
Running Process = 0
のエラーが出ていたことが分かる- 同じ画面で、SQSやDynamoDB,k8s,Lambda,S3の様子もリアルタイムで分かる
- Entitiesでより深く探っていく
- NASAが天文学的な(広視野的)スケールからミクロのスケールまで扱っているように、我々もそうする
- 広視野的 : k8s cluster explorer
- nodeをクリックし、何が起こっているか詳細を確認する
- node nameでフィルタ、フロントエンドで何が起きているか
- ログビューとテンポラリイベント
- ログビュー
- 前後3秒間に何が起きたかを確認
- コンテナ名 +
error
文字列でフィルタ
- イベントビュー
- コンテナが作成された後、リスタートしている
- 分散(distributed)トレーシングで調査
- フロントエンドからバックエンドまで、スタックトレースレベルで何が起こっているかを把握できる
- 次に、どう管理するのが良いかの話
- Optimizeメニューから、適切なリソース設定のサジェストも受けられる
- インスタンスタイプを変更しろ、など
- まとめ
- 完全な可観測性のための、簡単に使えるウィザードとツール
- どうモニタリングするかをコード化し、コードパイプラインをモニターする
- システムをリーン(lean)に設計し、地球を居住可能なまま(Green)に保とう(コスト最適化)
- lean と green で韻を踏んでいる(会場笑)
- 効果的な可観測性・信頼性モデル
- SREの観点でFailure Mode(故障モード)を設定
- 1〜1000の範囲でRRN(Risk Reference Number)を設定
- A : ページの表示が遅くなる = RRN 900
- B : ビジネス的な障害 = RNN 1000
- C : マイクロサービス間のレイテンシ増大 = RRN 800
- などなど
- SLI = サービスレベル指標(何をもって評価するか)
- A : 95パーセンタイルのページ表示速度
- SLO
- SLA
- ビジネスにどのくらいシビアかを考えて SLI , SLO、SLA を決める
まとめ
実際に動作するアプリケーションに実際にトラフィックを発生させ、可観測性的観点で分析するという、デモ中心のセッションでした。実際にアプリケーションを開発している方にとってはイメージの沸きやすい手法だったのではないかと思います。アプリケーションのシチュエーションもユニークですねw
デモが中心なので、是非(その部分だけでよいので)動画をご覧頂ければと思います。
ただし余談ながら、アプリケーションに送信されたメッセージの中にはHTMLインジェクションを狙ったものもあったようですw エンジニア相手のデモ目的とは言え(だからこそ?)セキュリティは重要ですね!